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SECTION  I.  INTRODUCTION 


This  report  is  for  research  performed  under  contract  N00014-80-C-0493.  The 
research  is  part  of  a  multi-disciplinary  program  concerned  with  design  for  maintainability. 
The  objective  of  this  component  has  been  to  investigate  generalized  methods  for  measuring 
and  predicting  maintainability  characteristics  of  an  equipment  as  a  consequence  of  its  internal 
structure  and  of  the  design  of  the  man-machine  interface. 


Background 

In  recent  years  we  have  been  concerned  with  understanding  the  ways  expert 
diagnosticians  conduct  fault  isolation  activities  as  a  function  of  their  knowledge,  the 
constraints  present  in  the  maintenance  environment,  and  the  architecture  of  the  system 
design.  A  key  outcome  of  this  research  has  been  the  development  of  a  generic 
(device-independent)  model  of  troubleshooting  behavior  which  can  be  applied  to  a  wide 
range  of  specific  equipments  (Towne,  1984, 1986).  The  model,  termed  PROFILE, 
generates  a  detailed  sequence  of  testing  actions  required  to  isolate  any  fault  of  interest  When 
standard  times  are  retrieved  for  each  of  the  detailed  maintenance  actions,  a  total  time  to 
diagnose  and  repair  is  obtained.  Doing  this  over  a  large  sample  of  representative  failures 
produces  a  distribution  of  corrective  maintenance  times  which  provide  a  measure  of  the  likely 
corrective  maintenance  workload  implied  by  the  system  design  and  the  maintenance 
conditions. 


When  provided  complete  data  about  the  internal  design  of  a  system,  PROFILE'S 
troubleshooting  sequences  are  near-optimal,  and  appear  very  much  like  those  of  expert 
maintenance  technicians.  Exhaustive  studies  (Towne,  Johnson,  &  Corwin,  1982, 1983) 
comparing  PROFILE  performance  to  that  of  actual  technicians  have  yielded  some  insights 
into  the  ways  in  which  poorer  maintainers  differ  from  experts.  The  studies  showed  that 
varying  the  precision  of  fault  effect  knowledge  in  the  model  produced  variations  in  diagnostic 
performance  very  much  like  those  observed  in  human  technician  samples,  whereas  varying 
the  troubleshooting  strategy  effectiveness  did  not.  As  a  result  of  these  findings,  PROFILE 
has  been  configured  to  accept  either  perfect  fault-effect  data,  to  produce  near  optimal  fault 
isolation  sequences,  or  somewhat  degraded  data,  to  simulate  the  performance  of  a  more 
typical  technician  population. 


Applications 


PROFILE  can  be  applied  in  at  least  the  following  five  ways: 

•  to  evaluate  an  equipment  design  for  its  maintainability  characteristics; 

•  to  support  an  intelligent  maintenance  training  system  that  can  evaluate  a 
learner's  diagnostic  strategies  and  can  recommend  preferred  approaches; 

•  to  generate  fault  isolation  strategies  to  be  provided  in  technical  documentation 
or  to  be  executed  as  automated  tests; 

•  to  determine  the  workload  implications  of  various  repair  policies; 

•  to  assist  in  the  identification  of  actual  failures  in  the  field. 

To  date,  PROFILE  has  been  applied  experimentally  in  the  first  two  of  these  ways. 
These  will  be  described  in  sections  in  and  IV,  following  an  updated  summary  of  PROFILE 
operation  in  Section  II.  Section  V  presents  conclusions. 


SECTION  IL  SYSTEM  SUMMARY 


PROFILE  is  a  form  of  expert  system  whose  rules  have  been  generalized  and  built  into 
the  model,  rather  than  expressed  as  domain-specific  data.  The  primary  advantages  of 
following  the  generic  approach  are  (1)  the  cost  and  effort  of  capturing  the  necessary 
system-specific  data  are  kept  modest,  (2)  the  quality  of  diagnostic  prescriptions  generated  by 
PROFILE  are  not  dependent  upon  an  individual  expert's  skill,  attention  to  detail,  and  recall 
abilities  (in  specifying  a  particular  diagnostic  approach),  (3)  the  process  can  be  used  to 
generate  diagnostic  sequences  under  widely  varying  conditions,  including  student-created 
conditions  and  conditions  of  interest  to  a  designer,  and  (4)  the  analyses  are  consistent  and 
repeatable  as  they  are  not  subject  to  individual  differences  in  troubleshooting  style.  These 
advantages  have  come  at  the  cost  of  conducting  research  leading  to  the  characterization  of 
diagnostic  performance  in  a  generalized  manner. 

Organization  of  the  Model 

The  organization  of  the  model  is  a  highly  structured  set  of  generic  troubleshooting 
rules  and  associated  metrics  computed  by  specialized  functions.  The  rules  and  metrics  were 
developed  over  a  period  of  several  years,  and  were  the  result  of  extensive  experimental 
observations  of  human  diagnostic  performance  and  of  studies  of  alternative  diagnostic 
strategies  (Towne,  Fehling,  and  Bond,  1981).  The  model  performs  three  basic  functions  at 
each  step  of  a  corrective  maintenance  problem:  (1)  test  selection,  (2)  test  "performance",  and 
(3)  symptom  interpretation.  Test  performance  within  the  model  involves  recording  that  the 
selected  test  would  be  done  by  the  simulated  maintenance  expert  and  updating  internal 
records  of  the  symptom  information  obtained  and  the  state  of  the  system.  The 
selection-performance-interpretation  cycle  is  repeated  until  the  true  failure  is  identified  and 
resolved.  The  organization  of  the  data  and  processes  is  shown  in  Figure  1. 

The  specifications  for  a  particular  equipment  are  cont  ained  in  the  design  specifications, 
in  Figure  1.  The  remainder  of  the  system  consists  of  generic  fault  isolation  processes  (the 
test  selector,  the  test  performer,  and  the  test  interpreter),  some  subordinate  utility  functions 
(time  calculator  and  test  value  calculator),  plus  working  memory  which  reflects  current 
suspicion  levels  and  the  current  state  of  the  internally-simulated  equipment 
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Figure  1.  PROFILE  System  Organization. 


Test  Selection 


The  model  considers  any  action  which  can  yield  new  information  to  be  a  test,  thus 
front  panel  tests,  use  of  test  equipment  at  internal  test  points,  adjustments,  and  replacing 
suspected  components  are  all  candidates  for  performance  at  each  stage  of  a  problem.  To 
select  the  next  diagnostic  action,  the  test  selector  function  shown  in  Figure  1  first  computes 
the  time  required  to  perform  each  possible  action  and  the  expected  utility  of  each. 

The  time  calculator  function  determines  those  actions  which  must  be  performed  to 
accomplish  the  test  under  consideration  and  the  time  those  actions  will  take.  The 
determination  of  required  actions  includes  a  search  algorithm  for  selecting  those  actions 
which  will  transition  the  system  from  its  current  state  to  the  state  required  for  performing  the 
test  under  consideration.  The  test  value  calculator  examines  the  fault-effect  data  to  determine 
what  information  would  be  obtained  from  each  test  outcome.  After  these  two  utility 
functions  have  yielded  their  results,  for  all  available  tests,  the  test  selector  chooses  that  one 
which  minimizes  the  expected  time  to  identify  the  fault  This  is  done  by  finding  the 
minimum  of  the  term: 

[TEST  TIME  +  EXPECTED  COMPLETION  TIME] 

where  TEST  TIME  is  the  time  to  perform  the  test  (which  is  conditional  upon  the  current  state 
of  the  system)  and  EXPECTED  COMPLETION  TIME  is  the  best  estimate  of  the  time  to 
complete  the  diagnosis  following  the  test.  By  selecting  the  test  which  minimizes  this 
expression,  the  model  is  finding  the  test  which  produces  the  most  gain,  assuming  that  only 
one  more  test  will  be  made.  This  heuristic  is  a  form  of  suboptimization  which  allows  rapid 
computation  of  excellent  diagnostic  approaches.  Because  the  exploration  of  solution 
possibilities  is  not  exhaustive,  however,  the  generated  diagnostic  sequences  are  not 
guaranteed  to  be  optimal. 

Because  test  performance  times  and  expected  test  utilities  can  change  radically 
following  any  single  action,  these  measures  must  be  recomputed  at  each  stage  of  a  fault 
isolation  sequence.  Furthermore,  a  sizable  sample  of  failures  must  be  analyzed  to  provide  a 
reliable  indication  of  the  expected  maintenance  workload.  As  a  result,  the  analysis  process  is 
highly  compute-bound. 

The  scheme  described  above  for  selecting  tests  represents  a  slight  revision  of  the 
algorithm  reported  earlier.  The  process  used  until  recently  selected  that  test  which  maximizes 


>*> 


I 

I 

the  ratio  of  new  information  (about  the  source  of  the  failure)  to  test  time.  This  metric  almost 
always  produces  rational  decisions,  but  encounters  a  scaling  problem  (see  Appendix  A) 

|  which  could  yield  irrational  decisions  in  some  extreme  cases.  A  further  disadvantage  of  the 

ratio  is  that  it  could  not  be  used  to  select  replacements  or  tests  just  prior  to  replacements, 
called  "direct"  tests.  As  a  result,  two  additional  rules  were  previously  required  for  these 
special  needs. 

While  the  revised  algorithm  yields  results  identical  to  the  earlier  one  in  most  cases,  this 
newer  formulation  avoids  the  scaling  problems  and  it  can  be  used  to  select  all  tests  and 
!  replacements.  Thus  the  PROFILE  model  is  now  simpler  and  somewhat  more  elegant  than 

[  before,  and  it  functions  appropriately  within  all  ranges  of  time  and  cost. 

Test  Performance 

The  model  simulates  the  performance  of  the  selected  test  by  (1)  adding  the  time  to 
perform  the  test  to  the  cumulative  time  to  resolve  the  problem,  and  (2)  retrieving  from  the 
fault-effect  data  the  symptom  which  the  "actual"  (assumed)  fault  would  yield.  This  symptom 

I 

is  passed  to  the  test  interpreter  function  for  assessment. 

Test  Interpretation 

The  test  interpreter  function  scans  the  fault-effect  data  to  determine  the  significance  of 
the  test  symptom,  and  it  revises  the  current  suspicion  levels  of  the  possible  faults  by 

I 

considering  the  similarities  between  the  symptoms  received  and  those  possible  from  each 
[  malfunction. 

j  Phases  of  a  Diagnostic  Problem 

I 

While  the  cycle  of  selecting,  performing,  and  interpreting  tests  is  carried  out  repeatedly 
by  the  model,  this  occurs  under  three  somewhat  different  conditions:  ( 1 )  initially  in  a  fault 
isolation  process,  prior  to  the  observation  of  any  abnormal  indications,  (2)  when  the  selected 
test  does  not  involve  replacement  of  a  suspected  part,  and  (3)  when  the  selected  test  does 
involve  replacement  of  a  suspected  part. 

Figure  2  reflects  these  three  basic  phases,  each  of  which  involves  the  test  selector,  test 
performer,  and  test  interpreter,  however  their  particular  operation  changes  somewhat 
depending  upon  the  phase  of  the  diagnostic  process.  While  the  search  for  abnormality  is 
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always  done  first  in  a  problem,  PROFILE  may  shift  between  testing  and  replacing  multiple 
times  in  a  problem,  as  described  below. 

Search  for  Abnormality 

The  upper  loop  in  Figure  2  reflects  a  search  by  PROFILE  for  some  abnormal 
symptom.  This  causes  the  model  to  begin  troubleshooting  by  testing  major  critical  functions, 
each  of  which  involves  as  much  of  the  system  as  possible.  During  this  phase  the  test  selector 
implements  a  rule  of  searching  the  fault  effect  data  for  the  test  which  maximizes  the 
probability  of  detecting  an  abnormality.  In  information-theory  terms,  as  applied  later  in  a 
problem,  a  test  which  meets  this  criterion  is  often  a  poor  test  for  fault  identification  purposes, 
but  is  an  effective  test  for  getting  started. 

When  PROFILE  starts  a  fault-isolation  process,  the  probability  (suspicion  level)  of 
each  RU  is  set  according  to  its  generic  reliability.  In  this  manner,  the  inherent  failure 
likelihoods  of  components  initially  tend  to  draw  PROFILE'S  testing  toward  unreliable  areas 
of  the  system.  Generally,  the  reliability  information  is  simply  that  related  to  each  generic 
component  in  the  system.  If  component  reliabilities  change  drastically  in  a  particular  system 
configuration,  however,  they  may  be  revised  to  reflect  the  impacts. 

If  all  major  functions  of  the  equipment  are  found  to  be  normal,  then  the  diagnosis  ends 
with  no  evidence  of  failure.  This  diagnosis  sequence  provides  a  measure  of  the  time  and 
maintenance  actions  required  to  check  out  a  functioning  system  (one  of  the  most  common 
maintenance  situations  at  the  depot  level).  If,  however,  some  abnormal  function  is  observed, 
then  the  model  shifts  to  the  standard  cycle  of  selecting  tests  based  upon  minimization  of 
expected  completion  time. 

T est  performance 

The  middle  section  of  the  flow  diagram  is  the  main  cycle  in  which  the  test  selector,  test 
performer,  and  test  interpreter  operate  to  select  tests  and  update  suspicion  levels.  When  the 
selected  test  does  not  involve  replacement  of  a  suspected  unit,  the  cyclic  execution  of  the 
three  functions  continues  without  interruption. 

Replacement 

Invariably  in  a  diagnostic  problem  in  which  some  failure  does  exist,  PROFILE  will 
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find  that  a  lower  expected  completion  time  is  achieved  from  replacing  some  suspected  part 
than  from  performing  another  "conventional"  test  This  occurs  because  the  current  suspicion 
level  of  the  part  has  reached  a  level,  from  completed  tests,  which  warrants  its  replacement 
followed  by  a  "confirming"  test  to  see  if  the  abnormality  disappears.  Because  the 
replacement  plus  confirming  check  provide  some  new  information  (about  one  particular 
part),  it  is  considered  a  test,  and  is  evaluated  for  potential  value  in  exaedy  the  same  way  as 
are  other  tests. 

Because  the  information  value  of  a  replacement  is  usually  very  low,  and  the  time  cost 
is  often  high,  PROFILE  rarely  selects  a  replacement  until  it  has  performed  more  informative 
tests.  Adjustments  followed  by  confirming  tests,  are  somewhat  more  attractive  in  general,  as 
they  usually  do  not  involve  extensive  disassembly.  Replacements  are  further  penalized  with 
the  cost  of  the  spare  part  being  replaced,  so  that  replacements  are  not  often  performed  until 
there  is  high  certainty  that  the  failure  has  been  identified.  This  rule  is  weakened,  however, 
when  time  pressure,  as  specified  by  a  user  parameter,  is  extreme.  In  this  case  expensive 
components  and  subassemblies  may  be  replaced  by  PROFILE  in  its  effort  to  minimize 
restoration  time  without  regard  for  the  associated  consumption  of  spares.  In  all  cases,  more 
expensive  spares  are  less  likely  to  be  replaced  than  cheaper  ones,  all  other  factors  being 
equal. 

Upon  choosing  to  replace  a  part,  the  model  sets  the  part's  suspicion  level  to  zero;  it 
adds  on  the  time  to  accomplish  the  replacement  and  any  associated  shut-down,  disassembly, 
reassembly,  and  restart  operations;  and  then  it  investigates  the  advisability  of  also  replacing 
other  associated  parts  which  share  a  high  suspicion  level  and  are  easily  accessed  at  this  time. 
If  PROFILE  finds  that  further  replacements  make  sense  from  a  time  minimization  standpoint, 
it  will  also  call  for  replacing  these,  usually  inexpensive,  components  as  a  group,  without 
further  intervening  tests.  This  is  called  "gang  replacement". 

Following  replacement  of  one  or  more  parts,  the  model  selects  a  "confirming  test"  (see 
the  lowest  portion  of  Figure  2),  which  is  the  quickest  previously-performed  test  which 
yielded  an  abnormal  symptom.  If  the  confirming  test  is  now  normal,  the  repair  is  completed. 
Otherwise,  further  testing  continues. 
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Figure  2.  PROFILE  Diagnostic  Logic. 
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Behaviors  of  the  Model 


The  simple  expression  for  test  value  given  above  yields  surprisingly  diverse  diagnostic 
behaviors  under  differing  situations.  As  just  mentioned  it  drives  the  diagnostic  model  toward 
efficient  performance,  with  which  an  expert  would  agree.  In  addition  to  avoiding  costly 
replacements,  as  discussed  above,  PROFILE  exhibits  these  characteristics  as  well: 

a.  it  generally  performs  front-panel  checks  prior  to  calling  for  test  equipment  usage, 
since  the  first  use  of  test  equipment  involves  a  considerable  set-up  time  cost  Once 
a  particular  test  equipment  has  been  used,  PROFILE  prefers  its  use  to  other 
equipments,  since  further  testing  with  it  is  economical. 

b.  if  Toiown-good’  spares  are  available  for  short-term  substitution,  it  will  use  these  if 
the  time  to  swap  diem  in  and  out  is  low,  since  the  cost  of  using  these  spares  is 
considered  to  be  negligible. 

c.  it  can  'profit'  from  past  field  experience,  if  component  reliabilities  are  maintained 
to  reflect  their  true  values.  All  other  factors  being  equal,  PROFILE  will  pursue  the 
testing  of  less  reliable  areas  of  a  system. 

d.  it  recognizes  tests  which  produce  outcomes  which  can  be  more  easily  interpreted, 
in  terms  of  relating  the  symptoms  received  to  the  possible  causes.  As  a  result,  it 
tends  to  generate  testing  sequences  which  are  lower  in  cognitive  difficulty  than 
would  a  process  only  concerned  with  maximizing  information 

Because  there  is  uncertainty  (for  a  human  maintainer  and  for  the  PROFILE  test 
selector)  about  what  symptom  will  actually  be  obtained  when  a  test  is  performed,  the  model 
will  at  times  select  a  test  which  turns  out  to  provide  little  new  information  even  though  it  had 
the  potential  of  providing  considerable  new  information.  Furthermore,  PROFILE  may  at 
times  replace  units  which  are  not  the  actual  faulty  unit  When  this  is  done,  however,  it  can 
be  shown  that  making  the  replacement  was  a  rational  decision  considering  the  cost  of  further 
testing  versus  the  suspicion  level  of  the  unit,  its  time  to  replace,  and  its  cost. 

Cognitive  Time 

PROFILE  computes  the  total  manual  time  to  perform  a  diagnostic  sequence  by 
summing  predetermined  standard  times  of  all  the  operations  which  are  required  to  perform 
the  generated  sequence.  These  times  can  be  produced  using  conventional  industrial 
engineering  techniques  such  as  synthetically  assembling  times  from  basic  micromotions  or 
performing  timed  studies  of  the  particular  operations. 

Detailed  studies  of  diagnostic  performance  (Towne,  1985)  revealed  a  relatively  reliable 
measure  of  cognitive  time  as  a  function  of  the  manual  times  of  the  individual  operations  and 


of  the  number  of  testing  operations.  In  general,  it  was  found  that  cognitive  time  preceding  a 
test  increases  when  the  associated  manual  time  increases,  although  the  cognitive  time  quickly 
reaches  an  asymptotic  value.  Furthermore,  a  component  was  identified  which  was  related 
solely  to  the  number  of  tests  required  to  resolve  a  problem,  possibly  reflecting  some  aspects 
of  problem  difficulty.  Comparing  the  empirically-derived  projections  to  the  actual  mean 
cognitive  times  over  thirty  different  problems  yielded  a  multiple  R  of  0.755  (F=37.082; 
d.f.=2,26). 

Since  the  empirical  formulation  was  derived  from  this  same  data,  we  can  only  know 
for  sure  that  the  function  is  relatively  significant  for  this  body  of  data.  It  is  encouraging, 
however,  that  the  function  relates  well  to  each  of  the  three  individual  experimental  studies 
comprising  the  thirty  problems  in  the  data.  The  cognitive  time  function  has  been  added  to  the 
model  so  that  distributions  of  total  projected  performance  time  (cognitive  plus  manual)  are 
provided  as  well  as  distributions  for  manual  time  alone. 

Cognitive  Difficulty 

Research  during  the  contract  period  also  endeavored  to  explore  promising  avenues  for 
measuring  the  variables  affecting  cognitive  difficulty  during  fault  diagnosis.  This  formidable 
area  becomes  somewhat  penetrable  when  the  diagnostic  sequences  generated  by  PROFILE 
are  used  as  the  basis  for  investigating  the  information  processing  which  may  accompany 
those  projected  performances.  If  the  PROFILE-generated  performance  for  a  particular  fault 
is  somewhat  representative  of  that  human  technicians  would  perform,  then  the  symptom 
information  and  fault-effect  data  which  are  involved  in  selecting  and  interpreting  tests  become 
rather  well-defined.  While  the  processes  actually  performed  are  not  known,  the  PROFILE 
rule-base  and  execution  process  may  be  sufficiently  realistic  to  provide  a  primitive  basis  for 
assessing  cognitive  workload. 


SECTION  in.  APPLICATION  OF  PROFILE  TO  ANALYSIS  OF  DESIGN 


When  used  as  a  design  analysis  tool,  PROFILE  generates  explicit  testing  sequences  to 
isolate  and  repair  each  of  a  sample  of  failures,  it  accumulates  the  estimated  time  to  perform 
each  diagnostic  sequence,  and  it  keeps  track  of  the  reasons  for  excessive  fault  resolution  time 
Among  its  summary  values  reported  to  the  user  are  the  following  (Towne  and  Johnson, 

1984): 

a.  the  distribution  of  repair  times,  with  mean  time  to  repair; 

b.  an  analysis  of  the  utilities  of  all  indicators  and  test  points.  This  can  highlight 
maintenance  features  which  are  redundant  or  of  marginal  value,  considering  their 
production  cost; 

c.  an  analysis  of  false  replacements,  indicating  those  components  which  are  likely  to 
be  consumed  in  quantities  greater  than  their  failure  rates  would  indicate.  This  also 
focuses  attention  on  needs  for  additional  indicators  and  test  points,  to  discriminate 
between  parts  which  produce  identical  symptoms  under  the  current  design; 

d.  a  summary  of  the  types  and  frequencies  of  maintenance  actions  required  to  resolve 
the  sample  of  faults,  and  the  proportion  of  time  spent  performing  those  functions. 

Figure  3  illustrates  the  general  design  process  as  it  would  currently  be  carried  out  with 
PROFILE  support.  Upon  developing  a  design  which  meets  the  functional  requirements  of  the 
system,  the  designer  enters  schematic  diagrams  representing  the  system  architecture. 

Following  this,  a  repetitive  cycle  is  followed  involving  the  analysis  of  maintainability 
characteristics  and  the  correction  or  improvement  of  maintainability  weaknesses.  Because 
PROFILE  is  not  now  integrated  with  a  commercial  CAD/CAE  (computer  aided 
design/computer  aided  engineering)  system,  the  accomplishment  of  the  functional  design  and 
the  entry  to  PROFILE  are  required  to  be  two  separate  steps.  The  preparation  of  special 
PROFILE  diagrams  will  become  unnecessary  when  it  can  be  integrated  into  a  commercial  CAE 
system.  Work  is  in  progress  to  embed  the  PROFILE  model  in  the  MentorGraphics  IDEA  CAE 
system. 


Extracting  Required  Inputs  From  Design  Specifications 

To  operate  upon  a  particular  system,  PROFILE  requires  the  following  information: 

a.  a  list  of  the  replaceable  units  (RU's)  in  the  system,  along  with  their  interconnections; 

b.  a  list  of  possible  test  points  and  indicators; 

c.  the  disassembly  sequences  required  to  gain  access  to  internal  parts  and  test  points; 

d.  the  physical  groupings  of  components  into  modules,  boards,  units,  etc. 
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Figure  3.  The  PROFILE-Supported  Design  Process 

A  long-term  objective  of  the  research  has  been  to  develop  ways  to  extract  these  data 
items  from  the  representations  built  up  during  the  computer-aided  design  process.  A  special 
graphics  interface  was  developed  to  facilitate  experimentation  with  PROFILE  in  a  design 
setting,  and  to  determine  the  feasibility  of  developing  a  general  interface  between  it  and 
commercial  CAE  systems.  This  suite  of  programs  allows  a  designer  to  (1)  enter  system 
schematics  in  block  diagram  form  and  to  provide  the  generic  identification  of  each  element,  and 
(2)  execute  a  system  simulation  which  automatically  introduces  failures  into  the  system  and 
computes  the  effects  of  those  failures  at  the  indicators  and  test  points.  Included  in  this  resource 
is  a  prototype  library  of  generic  objects,  containing  representative  costs,  reliabilities,  and 
replacement  times. 

The  identification  of  system  components  is  trade  in  terms  of  generic  parts  whose 
characteristics  have  been  predefined  in  a  library  of  system  components.  The  generic 


description  for  a  part  specifies  its  approximate  reliability,  cost,  and  the  fixed  portion  of  the 
time  to  replace  (assuming  that  obstructing  parts  have  been  removed).  A  second  library,  a 
standard  task  library,  contains  standard  times  to  perform  common  maintenance  tasks  such  as 
making  various  test  readings,  setting  up  test  equipment,  and  removing  and  replacing  various 
types  of  fasteners.  By  combining  the  fixed  replacement  times  with  the  times  to  remove  and 
replace  various  fasteners,  according  to  the  disassembly  requirements  specified  for  the 
equipment,  PROFILE  computes  the  times  to  access,  test,  and  replace  internal  parts. 

Providing  the  system-specific  data  to  PROFILE  is  a  relatively  straightforward  task  which 
does  not  require  a  diagnostic  expert.  Systems  which  have  been  designed  using  a  commercial 
CAD/CAE  system  can  be  readily  analyzed  by  PROFILE,  as  the  bulk  of  necessary  data  are 
present  within  the  captured  schematic  diagrams  (although  there  is  currently  no  interface 
between  these  commercial  systems  and  PROFILE).  One  type  of  design  information  must 
usually  be  added,  as  it  is  rarely  captured  within  CAD/CAE  processes.  This  is  a  specification  of 
the  manner  in  which  the  functional  units  are  packaged,  i.e.,  the  order  in  which  parts  must  be 
disassembled  to  gain  access  to  internal  parts. 

While  this  experimental  graphics  interface  is  not  as  sophisticated  as  commercial  CAE 
systems,  it  does  provide  a  self-contained  approach  to  specifying  and  analyzing  system  designs, 
rhere  are  many  powerful  CAE  systems  which  perform  the  two  necessary  functions  for 
supporting  PROFILE  analysis:  (1)  capturing  system  schematics,  and  2)  simulating  faults. 
Systems  exist  for  capturing  and  simulating  both  analog  and  digital  technologies,  although  the 
majority  of  CAE  resources  are  devoted  to  specification  and  analysis  of  digital  systems.  The 
great  majority  of  these  system  simulators  are  also  based  upon  some  version  of  SPICE  (Nagel 
&  Pederson,  1973;  Nagel,  1975).  It  is  clear  that  PROFILE  can  be  tailored  to  communicate 
with  the  design  file'  created  by  most  of  these  systems.  The  design  file  contains  the 
system-specific  specifications  of  the  interconnections  and  component  types.  It  is  our  intention 
to  create  the  interface  between  one  of  the  leading  CAE  packages  to  operate  in  conjunction  with 
PROFILE. 

A  Sample  Application 

Appendix  B  presents  a  complete  application  of  PROFILE  to  an  infrared  (IR) 
transmitter/receiver  system  built  for  the  purpose  of  obtaining  realistic  diagnosis  and  repair  data. 
An  earlier  report  (Towne,  Johnson,  and  Corwin,  1983)  presents  the  maintenance  time 
predictions  and  actual  observations.  Appendix  B  presents  the  inputs  to  PROFILE  in  the 
graphical  form  which  was  developed  after  the  original  study  and  the  maintainability  analysies. 


SECTION  IV.  A  TRAINING  APPLICATION 


We  are  currently  using  PROFILE  within  the  Intelligent  Maintenance  Training  System 
(IMTS),  a  computer-based  training  system  whose  function  is  to  interact  in  intelligent  ways  with 
learners  who  are  practicing  troubleshooting  (Towne,  1987;  Towne,  Munro,  Pizzini,  and 
Surmon,  1987).  The  approach  used  in  the  IMTS  for  relating  the  graphical  appearance  of  an 
object  to  its  role  and  state  within  a  particular  system  was  heavily  influenced  and  inspired  by 
work  on  a  simulation  system  called  STEAMER  (Hollan,  Hutchins,  and  Weitzman, 
1984;Hollan,  1983).  STEAMER  allows  experts  to  construct  interfaces  between  existing 
simulations  of  particular  systems  to  graphical  "objects"  which  display  their  response  to  system 
conditions.  When  attached  to  a  particular  system  by  a  content-expert,  the  objects  determine 
how  they  react  to  their  inputs  and  how  they  appear  under  any  condition.  Thus,  as  a  student 
alters  the  system  configuration,  by  setting  switches,  the  intelligent  objects  respond  and  appear 
appropriately. 

Our  objectives  have  been  (1 )  to  produce  an  object  editor  and  a  system  editor  which  can 
be  used  by  non-programmers  to  create  new  objects  and  systems,  (2)  to  develop  a  system 
simulator  which  will  respond  correctly  as  a  learner  alters  switches  and  attaches  simulated  test 
equipment,  and  (3)  to  embed  PROFILE  into  this  simulation  environment  to  intelligendy  assess 
the  learner's  diagnostic  approach. 

Graphics-based  Specification  for  Training  Applications 

For  analysis  of  designs  and  generation  of  diagnostic  specifications  it  is  not  important  that 
the  fault  simulator  create  graphic  representations  of  the  symptoms  resulting  at  each  test  point  or 
of  the  operational  states  of  the  elements.  For  training  purposes,  however,  the  graphic 
representation  of  fault  effects  and  system  function  is  critically  important. 

The  system  used  to  create  the  graphics  and  fault  information  required  for  training  is 
shown  in  Figure  4.  The  system  includes  I )  an  object  construction  editor  for  defining  generic 
objects  (both  their  graphic  appearance  and  their  functions),  2)  a  system  construction  editor 
for  combining  the  generic  objects  into  specific  system  diagrams,  and  3)  a  fault  simulator 
capable  of  determining  the  symptoms  produced  by  each  possible  fault  These  elements  form  a 
type  of  CAD/CAE  system,  but  one  which  can  also  support  training. 
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A  Generic  CAD/CAE  System 


Figure  4.  Simulation  Composition  System 


Creating  New  Objects 


If  the  simulation  author  finds  that  the  existing  library  of  generic  objects  lacks  a  required 
object,  he  or  she  constructs  it  using  an  object  editor.  This  involves  constructing  the  graphic 
representations  for  the  part  in  its  possible  states,  and  entering  rules  which  govern  its  behavior. 
The  rules  for  an  object  are  of  two  types  ( 1 )  system  condition  rules,  which  state  the  conditions 
which  cause  an  object  to  enter  its  various  states,  and  (2)  performance  effect  rules,  which  state 
what  operations  the  object  performs  in  each  of  its  states.  Figure  5  illustrates  a  two-state  object 
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with  the  system  conditions  and  performance  effects  for  each  state.  This  object,  a  Caliper 
Brake,  is  in  the  BRAKE-OFF  condition  if  the  pressure  at  the  input  port  (A)  is  less  than  200  psi 
or  if  more  than  50  pounds  of  pressure  is  exerted  at  the  brake  pads  (port  B).  When  in  this  state, 
the  object  exerts  no  force  at  the  brake  pads. 


State  Name 


Graphic 


System 

Condition 


Performance 

Effects 


((A  >-  200)  AND  (B  <  50)) 


(IF  (A  >=  200)  THEN  (B  <-  50) 
ELSE  (B<-  5)) 


Figure  5.  Graphics  and  Rules  for  a  Two-state  Object 


Constructing  New  Simulations  for  Training 


The  content-expert  constructs  a  specific  system  simulation  (and  all  associated  training 
interactions)  by  simply  selecting  (with  a  mouse)  appropriate  objects  from  the  library  and 
positioning  them  on  the  screen,  using  a  special  graphics  editor.  While  the  author  must  be 
certain  that  each  object  selected  actually  operates  as  the  real  object  in  the  system,  the  job  of 
constructing  the  simulation  is  primarily  one  of  subdividing  a  big  system  into  separate  screens, 
or  drawings,  and  then  producing  each  individual  diagram  in  the  editor  provided  with  the 
IMTS.  As  the  objects  are  positioned,  the  editor  detects  the  connections  between  elements,  and 
it  retains  the  connectivity  data  in  a  file.  While  the  connectivity  data  are  necessary  to  computing 
how  a  system  will  behave  under  a  current  condition,  these  data  are  a  small  part  of  the 
intelligence  used  to  simulate  the  system  behaviors.  The  IMTS  uses  the  connectivity 


information  plus  the  behavior  rules  of  each  object  involved  to  determine  the  nature  of  the  signal 
conversions,  and  hence  the  particular  appearance  of  system  indicators  and  associated  test 
equipment. 

Once  all  the  individual  diagrams  have  been  created,  and  outputs  from  one  diagram  have 
been  linked  to  inputs  to  others,  the  representation  is  completed.  IMTS  can  now  select  and 
insert  practice  malfunctions  for  each  student,  it  can  accept  and  display  the  results  of  student 
testing  actions,  it  can  monitor  each  learner  providing  individualized  assistance,  and  it  can 
demonstrate  expert  diagnostic  strategies  as  required. 


SECTION  V.  CONCLUSIONS 


The  PROFILE  model  has  been  found  to  generate  troubleshooting  behaviors  very  similar 
to  those  of  qualified  technicians  working  with  adequate  training,  facilities,  and  time  to  resolve 
single,  persisting  failures.  The  experimental  applications  indicate  that  use  of  the  technique  can 
sense  the  maintainability  implications  of  a  wide  range  of  design  alternatives  including  those 
concerning  packaging,  modularization,  test  point  provisions,  front  panel  design,  and  extent  of 
automated  test  facilities.  The  formalization  of  a  generalized  fault  isolation  process  has  also 
shown  that  not  all  false  replacements  are  the  result  of  poor  technician  decisions,  and  that  a 
substantial  portion  of  such  replacements  may  be  the  result  of  rational  decision  making  in  the 
face  of  an  imperfect  design  or  demanding  conditions  in  the  maintenance  environment. 
Application  of  the  model  also  verifies  what  field  technicians  already  know  --  that  under 
conditions  of  inadequate  time,  test  equipment,  or  training  a  rational  person  may  be  forced  to 
resort  to  radically  different  diagnostic  approaches.  There  is  some  analytical  evidence  that  the 
resulting  degradation  in  diagnostic  performance  does  not  occur  gracefully,  i.e.,  that  even  small 
deficits  in  necessary  resources  may  demand  major  shifts  in  approach.  Generally  this  shift  must 
be  toward  a  drastic  limiting  of  testing  operations  in  favor  of  substitution  of  large  units  of 
hardware. 

Perhaps  the  greatest  potential  for  future  research  lies  with  exploring  the  maintenance 
performance  implications  of  reduced  technician  knowledge,  as  a  result  of  reduced  training  and 
experience.  Some  equipment  designs  might  be  relatively  tolerant  to  reduced  proficiency  levels 
while  others  could  conceal  catastrophic  implications  which  become  known  only  when  the 
system  is  deployed.  System  A  in  Figure  6  below  is  one  which  is  relatively  insensitive  to  skill 
and  knowledge  deficits.  While  MTTR  increases  as  proficiency  decreases,  the  change  is 
relatively  gradual.  System  B,  however,  can  only  be  maintained  well  by  fully  qualified 
technicians.  Fault  isolation  of  such  a  system,  by  anyone  other  than  an  expert,  will  involve 
either  great  consumption  of  time  or  great  consumption  of  spare  parts. 

If  the  two  systems  are  compared  under  conditions  of  fully  qualified  technicians,  then 
system  B  appears  to  be  superior.  There  is  growing  evidence  that  systems  involving  highly 
automated  test  and  diagnostic  functions  offer  repair  time  profiles  something  like  that  of  system 
B.  If  a  mission  requirement  demands  an  MTTR  which  can  only  be  achieved  with  fully 
qualified  technical  skills,  then  it  is  crucial  that  the  associated  personnel  skill  levels  be  realized 
long  before  deployment. 
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Figure  6.  MTTR  versus  Technician  Proficiency  for  Two  System  Designs 

Of  course  some  would  say  that  the  resolution  to  the  problem  is  simply  to  adequately  train 
the  necessary  people  and  assign  them  to  the  maintenance  of  the  system.  While  this  is  always  a 
reasonable  attitude,  the  systems  which  supply  trained  people  to  the  field  are  also  complex  and 
are  also  subject  to  imperfections,  thus  it  makes  sense  to  consider  the  likelihood  of  personnel 
deficits  in  the  design  stage. 

The  major  practical  obstacle  to  introducing  quantitative  maintainability  analysis  into  the 
design  process  has  to  do  with  the  need  to  (1)  sufficiently  integrate  the  analysis  process  into  the 
CAD/CAE  systems  that  the  designer  is  not  hampered  by  the  tools  when  they  are  not  in  use,  and 
(2)  minimize  the  additional  activities  (beyond  those  required  to  produce  the  functional  design) 
which  are  required  to  support  maintainability  assessment.  Ideally,  the  designer  should  be 
unaware  of  the  maintainability  analysis  process  during  the  early  phases  of  design  in  which  the 
system  is  taking  form,  and  not  be  required  to  tend  to  satisfying  data  requirements  before  the 
data  are  available.  To  accomplish  this  will  require  that  the  majority  of  design  information 
required  by  PROFILE  be  automatically  extracted  from  the  design  file  created  by  the  commercial 
CAD/CAE  systems. 
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In  fact  it  appears  that  the  graphical  schematic  capture  routines  of  such  systems,  along 
with  their  system  simulation  routines,  may  provide  virtually  all  the  user  interface  features 
required.  The  MentorGraphics  CAE  system  (IDEA)  provides  the  capability  to  associate 
user-defined  properties  to  the  parts  entered  at  the  schematic  capture  stage.  This  would  allow 
for  assigning  the  design-dependent  information  required,  such  as  assembly /disassembly 
priority  and  possibly  design-dependent  reliability  data. 

The  second  practical  problem  which  will  persist  is  overcoming  excessive  compute 
delays.  The  two  most  promising  avenues  for  doing  this  appear  to  be  (1)  the  inevitable  increase 
in  raw  compute  speed  from  faster  computer  processors,  and  (2)  finding  more  efficient  search 
processes  for  selecting  tests.  The  latter  of  these  almost  certainly  will  require  a  deeper 
understanding  of  the  process  human  diagnosticians  employ  when  directing  their  testing 
performance. 
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APPENDIX  A 

Improvements  to  the  Test  Selection  Process 

Previous  versions  of  the  PROFILE  model  selected  the  next  test  in  a  sequence  as  the  test 
which  maximized  amount  of  new  information  contributed  by  the  test  divided  by  the  time  to 

perform  it.  New  information  is  the  reduction  in  uncertainty  ,  AU,  resulting  from  the  test 
calculated  as  U  -  U*  where  U  is  the  system  uncertainty  prior  to  the  test,  and  U'  is  system 

uncertainty  following  the  test.  System  uncertainty  is  measured  as  X  (pj  log  p^  ,  where  the  p{ 

are  the  probabilities  of  each  of  the  i  possibilities,  which  sum  to  1.0.  Uncertainty  is  zero  when 
one  of  the  probabilities  is  1.0  and  it  is  maximized  when  the  probabilities  are  distributed  equally 
among  all  the  possibilities. 

For  example,  suppose  a  system  consists  of  100  replaceable  units  (RU’s),  and  the 
current  probability  (based  on  symptoms  already  received)  that  RU1  is  failed  is  .98,  while  the 
probability  of  each  of  the  remaining  99  RU’s  is  0.0002  (0.02/99).  The  system  uncertainty  at 
this  point  of  the  problem  is  therefore  (using  logarithms  to  the  base  2): 

X  pj  log  pj  =  (.98)  log  .98  +  99  (.0002)  log  (.0002)  =-0.02857-0.24332  =-0.27189 


Suppose  there  are  no  more  conventional  tests,  thus  we  must  resort  to  replacement  to  finish  the 
problem.  The  uncertainty  which  would  result  from  replacing  RU1  (and  repeating  one  of  the 
tests  previously  yielding  an  abnormal)  is 

0.98  x  0  +  .02  x  99  x  .010  log  .010  =  0  -  0.13156  = -0.13156 

and  the  uncertainty  reduction  would  be  AU  = -0.27189  -  (-0.13156)  =  0.140 

whereas  the  uncertainty  resulting  from  replacing  any  one  of  the  other  RU’s  would  be 
.98  log  .98  +  .0002  x  0  +  98  x  .0002  log  .0002  =  -0.02857  +  0  -0.24086  =  -0.26943 
and  the  uncertainty  reduction  would  be  -0.27189  -  (-0.26943)  =  -.00246 

Now  if  the  time  to  replace  RUI  is  600  seconds,  then  AU/T  for  replacing  RU1  is 
.140/600  =  0.00023 


23 


If  the  time  to  replace  any  of  the  other  RU's  is  10  seconds,  then  AU/T  for  one  of  them  is 
.00246/10  =  .000246 

Thus  the  prior  rule  would  replace  each  of  the  RU's  2,  3, ....  100  before  finally  replacing  RU1. 

Yet  the  expected  time  to  solve  the  problem  with  this  strategy  is 

.0002  x  10  +  ..0002  x  20  +  ..0002  x  30  +  ..0002  x  40  +  ...  +  .0002  x  990  +  .98  x  (990  + 

600)  =  1570  seconds 

whereas  the  strategy  of  replacing  RU 1  first  has  the  expected  solution  time  of 
.98  x  600  +  .0002  x  610  +  .0002  x  620  +  ...  +  .0002  x  1590  =  610  seconds 

In  this  case,  the  old  measure  was  heavily  influenced  by  the  60  to  1  ratio  of  test  time  for 
replacing  RU1  compared  to  replacing  any  of  the  others.  This  same  ratio  could  have  been 
encountered  if  the  replacement  of  RU1  required  60  seconds  and  the  others  required  1  second, 
in  which  case  PROFILE  would  have  passed  up  making  a  one-minute  replacement  of  a  part  with 
a  .98  chance  of  being  the  malfunction  in  favor  of  replacing  parts  in  1  second  with  .0002  chance 
of  being  correct. 

In  actuality,  RU1  should  be  replaced  first  even  if  its  time  is  as  much  as  4,900  (.98/.0002)  times 
as  long  as  the  other  RU's  replacement  times. 

Under  the  new  test  selection  rule,  replacements  are  performed  in  descending  order  of 
probability  per  ''time-cost"  ratio  (P/T).  Note,  "time-cost"  is  a  function  of  replacement  time, 
confirming  test  time,  and  dollar  cost  of  the  RU.  This  strategy  can  be  shown  to  minimize 
expected  (average)  repair  time.  RU  1  has  a  P/T  ratio  of  .0016  (=.98/600),  while  each  of  the 
other  RU’s  have  a  P/T  ratio  of  0.00002  (=0.0002/10).  Hence  RU  1  would  be  replaced  first, 
and  then  successively  each  of  the  other  RU's,  until  the  system  was  found  to  be  operational.  In 
fact,  RU  1  would  be  replaced  first  unless  the  other  RU  time-costs  were  less  than  0.12  seconds 
(600/  (0.98  /  0.0002)),  in  which  case  replacing  each  of  the  other  RU's  first  would  be  the 
optimal  strategy. 
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Maintainbility  Analysis  of  an  Ifrared  Transmitter/Receiver 

Figure  B-l  presents  the  organization  of  the  infrared  (IR)  Transmitter/receiver.  Each  of  the 
fourteen  blocks  in  this  figure  represent  a  diagram  entered  to  PROFILE.  Figures  B-2  through 
B- 15  arc  those  fourteen  graphic  representations  of  the  IR  system. 

Figures  B-l 6  through  B-23  are  the  PROFILE  analyses  of  the  design  of  the  system. 
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Detailed  Diagnostic  Sequences 

These  list  the  testing  sequences  performed  to  isolate  each  failure,  the 
symptom  obtained  at  each  test,  and  the  time  taken  to  perform  each  test. 


********  New  problem:  l(ru-  37  bb-  1  FIBER  OPTIC  CABLE) 

Perform  Test  39  (Byte  2  Observe) 

XMIT  :  ON  time-  13 

REC  :  ON  time-  13 

Cogtime  (prior  to  above  T/R)  -  19 

Indie  39:1  (Abnorm) 

conditional  time  is  26,  total  man  is  28 


Perform  Test  15  (Phase-Lock  Check) 

Cogtime  (prior  to  above  T/R)  -  12 
Indie  15:1  (Abnorm) 

conditional  time  is  0,  total  man  is  3 


Perform  Test  8  (serial  data) 

SCOP E_COUP LE  :  DC  time-  2 

GROUND  :  BOARD 1  time-  10 

SCOPE_SWEEP  :  10 MS  time-  2 

Cogtime  (prior  to  above  T/R)  -  23 _ 

Indie  8:0  (Norm) 

conditional  time  is  14,  total  man  is  49 


Perform  Test  35  (Vcc5) 

CALIBRATE  :  YES  time-  7 

Cogtime  (prior  to  above  T/R)  -  17 
Indie  35:0  (Norm)  *critical* 

conditional  time  is  7,  total  man  is  19 


Replace  ru  10  741  OP  AMP  ** REPLACEMENT** 

REC  :  OFF  time-  7 

Cogtime  (prior  to  above  T/R)  -  23 

conditional  time  is  7,  total  man  is  53 

Perform  Test  39  (Byte  2  Observe) 

REC  :  ON  time-  13 

Cogtime  (prior  to  above  T/R)  -  16 

conditional  time  is  13,  total  man  is  15 


Replace  ru  37  FIBER  OPTIC  CABLE  * ‘REPLACEMENT** 

Cogtime  (prior  to  above  T/R)  -  21 

conditional  time  is  0,  total  man  is  40 

End  of  problem.  Man  time-  342.00  Cog  time-  551.00 
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Repair  TimesBy  Fault 

(in  ascending  order  of  time  -  times  include  diagnosis) 
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V 

y 

This  analysis  lists  the  projected  time  to  diagnose  and  repair  each  fault  in  the  « 

system.  When  PROFILE  resorts  to  replacement  to  resolve  an  inability  to  " 

determine  the  failure  by  testing,  it  randomly  varies  the  order  in  which  the  possible  '■*' 

failed  components  are  replaced. 


BB- 

Basic  block  number 

£• 

RU- 

Replaceable  Unit  number 

PROB- 

Probability  of  failure 

Mean  - 

Mean  Diagnosis  and  repair  time,  per  PROFILE 

s“ 

N 

Number  of  samples 

STD 

Standard  deviation  in  sample 

MIN 

Minimum  repair  time  in  sample 

MAX 

Maximum  repair  time  in  sample 

,V 

EXP 

Expected  repair  time  for  the  fault 

MANUAL  SOLUTION  TIME  SUMMARY  BY  FAULT 


BB 

RU 

FAULT  NAME 

PROB. 

MEAN 

N 

STD 

MIN 

MAX 

EXP 

21 

13 

10K  Pot 

0.029 

41.0 

1 

0.00 

41 

41 

1.17 

50 

36 

Latch  Wire 

0.007 

54.0 

1 

0.00 

54 

54 

0.39 

19 

36 

Data  Wire 

0.007 

54.0 

1 

0.00 

54 

54 

0.39 

1? 

36 

Shift  Wire 

0.007 

54.0 

1 

0.00 

54 

54 

0.39 

23 

15 

4001  QUAD  NOR 

0.029 

84.0 

1 

0.00 

84 

84 

2.40 

1  3 

30 

Man74  LED 

0.029 

85.0 

1 

0.00 

86 

86 

2.46 

51 

36 

Power  Wire 

0.007 

113.0 

1 

0.00 

113 

113 

0.81 

11 

31 

Man 7  4  LED 

0.029 

145.0 

1 

0.00 

145 

145 

4.14 

3 

3  3 

12  VOLT  POWER  SUPP 

0.029 

149.0 

1 

0.00 

149 

149 

4.26 

j 

* 

BCD  Switch (b ) 

0.014 

167.0 

1 

0.00 

167 

167 

2 . 39 

c. 

3  5 

Power  wire 

0 .014 

170.0 

1 

0 . 00 

170 

170 

2 . 43 

1  3 

4. 

4  0  1 3  A 

0.014 

184.0 

1 

0.00 

184 

184 

2.63 

1  9 

31 

power  lead 

0.014 

209.0 

1 

0.00 

209 

209 

2.99 

♦h 

BCD  Switch (a) 

0.014 

214 . 0 

1 

0 . 00 

214 

214 

3.06 

2  c, 

409  1  AND (b) 

0.010 

227 . 0 

1 

0 . 00 

227 

227 

2.16 

12 

r : 

4511  LATCH 

0.029 

239.0 

1 

0 . 00 

239 

239 

6.83 

31 

2  b 

4523  Div(b) 

0.014 

242  .  5 

2 

16.26 

231 

254 

3.46 

1 1 

2  0 

4511  LATCH 

0.029 

.3.0 

1 

0.00 

243 

243 

6.94 

•> 

;  *4 

Demodulator 

0.010 

258.0 

1 

0.00 

258 

258 

2.46 

1  ■' 

2  2 

Shifter 

0.010 

274.0 

1 

0 . 00 

274 

274 

2.61 

1  2 

4046  PHASE-LOCK 

0.029 

277 . 0 

1 

0 . 00 

277 

277 

7 . 91 

1  1 

"’ll  OP  AMP 

0.029 

277 . 0 

1 

0 . 00 

277 

277 

7.91 

2  1 

i «. 

"41  OP  AMP 

0.029 

277 . 0 

1 

0 . 00 

277 

2  77 

7.91 

2 

43  1  3B 

0.014 

289.0 

1 

0 . 00 

289 

289 

4  .  13 

'  c 

:  i 

Mi  xer 

0.010 

291.0 

1 

0.00 

291 

291 

2.77 

1  0 

"41  OP  AMP 

0.029 

298  .  0 

1 

0  .  00 

298 

298 

8  .  51 

;  *) 

"> 

4  c  2  0  D  I V  ( a  ) 

0.014 

313.0 

2 

19.80 

299 

327 

4  .  47 

:  >5 

'  t' 

0.010 

314.0 

1 

0 . 00 

314 

314 

2  .  99 

1  c 

2  2 

r  :.K.2 

0.010 

317.0 

1 

3  .  00 

317 

317 

3.02 

•  ► 

'  C, 

4  0  « 1  AND ( a  t 

3.010 

318  .  0 

1 

^0  .  00 

318 

318 

3.03 

Distribution  of  Repair  Times 
(including  diagnosis) 


MEAN  MANUAL  SOLUTION  TIME 


♦  *  * 

♦  *  *  * 


*  *  ******** 
>  *  *  ************ 


* 


0  121  241  362  482  603  724  844  965  1085  1206 

n-  53  mean-  324.9  std-207.24  1  pt3/' *' 


MEAN  MANUAL+COGNITIVE  SOLUTION  TIME 


* 


*  * 
*  *  *  *  *  * 


* 


****  **  ** 


* 


**********  **  *******  ** 


0  217  434  651  868  1085  1301  1518  1735  1952  2169 

n-  53  mean-  712.7  std-429.46  1  pts/' *' 


Analysis  of  Replacements 


FREQ  Number  of  times  the  replacement  was  made,  in  the  sample 

RAWTIME  Time  to  perform  the  replacement 

TOTAL  Total  time  spent  replacing  the  component,  in  the  sample 


ID 

REPLACEMENT 

FREQ 

RAWTIME 

TOTAL 

5 

CRYSTAL_32768HZ 

3 

420 

1260 

29 

Crystal 

3 

420 

1260 

6 

BCD  Switch (a) 

11 

80 

880 

8 

INFRA-RED  LED 

2 

420 

840 

36 

4  Lead  Ribbon  Conn 

33 

14 

462 

24 

4081a 

10 

46 

460 

26 

4520  DIV(a) 

9 

50 

450 

9 

2N222  TRANSISTOR 

1 

420 

420 

16 

Photo-Trans 

1 

420 

420 

25 

4081AND (b) 

8 

46 

368 

23 

4069a 

6 

46 

276 

28 

4060  CLOCK 

4 

50 

200 

17 

10K  Pot 

20 

10 

200 

27 

4013  D-FF 

4 

50 

200 

4 

4060  CLOCK  DRIVER 

3 

50 

150 

14 

4046  PHASE-LOCK 

3 

50 

150 

3 

4013  DUAL-D  FLIP 

3 

50 

150 

1 

4021  P/S  SHIFTER 

3 

50 

150 

22 

S/P  Converter 

3 

46 

138 

2 

4013  DUAL-D  FLIP 

2 

50 

100 

10 

741  OP  AMP 

2 

46 

92 

13 

4584  Schmitt 

2 

46 

92 

30 

Man 7 4  LED 

2 

46 

92 

31 

Man74  LED 

2 

46 

92 

21 

4511  LATCH 

2 

46 

92 

20 

4511  LATCH 

2 

46 

92 

37 

FIBER  OPTIC  CABLE 

2 

40 

80 

34 

Ribbon  Cable (2) 

4 

14 

56 

7 

4046  PHASE-LOCK 

1 

50 

50 

1  1 

741  OP  AMP 

1 

46 

46 

12 

741  OP  AMP 

1 

46 

46 

15 

4001  QUAD  NOR 

1 

46 

46 

35 

Ribbon  Conn. 

2 

14 

28 

32 

12  VOLT  POWER  SUPP 

1 

10 

10 

33 

12  VOLT  POWER  SUPP 

1 

10 

10 

Analysis  of  Testing  Frequency 


FREQ  Number  of  times  the  test  was  performed  in  the  sample 

TIME  Time  to  perform  the  test 

TOTAL  Total  time  spent  performing  the  test,  in  the  sample 


ID 

TEST 

FREQ  X 

TIME¬ 

TOTAL 

8 

serial  data 

19 

RS 

665 

31 

TP42 

23 

23 

529 

6 

Data  out 

13 

35 

455 

24 

TP4  9 

18 

23 

414 

10 

Ampl.  40/50khz 

18 

23 

414 

25 

TP4  6 

16 

23 

368 

39 

Byte  2  Observe 

155 

2 

310 

22 

Vcc3 

11 

23 

253 

36 

TP420 

10 

23 

230 

11 

40/50khz 

9 

23 

207 

41 

tp4 17 

4 

48 

192 

15 

Phase-Lock  Check 

64 

3 

192 

5 

70ns 

5 

33 

165 

32 

TP4 1 

7 

23 

161 

40 

tp4 18 

3 

48 

144 

37 

TP422 

4 

35 

140 

9 

Q1  to  Dinp 

4 

35 

140 

20 

TP  3  2 

6 

23 

138 

17 

TP37 

6 

23 

138 

23 

TP  4  14 

5 

23 

115 

30 

TP4  7 

5 

23 

115 

35 

Vcc5 

8 

12 

96 

18 

TP36 

4 

23 

92 

14 

TP33 

4 

23 

92 

28 

TP4  8 

4 

23 

92 

2 

8hz 
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23 
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23 

46 
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3 
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36 
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1 
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23 
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1 

23 

23 
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48 

0 

4 
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0 

23 

0 

3 
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0 

48 

0 

Analysis  of  Diagnostic  Values  of  Indicator  and  Test  Points 

li-REDCT  Uncertainty  reduction  when  the  indicator  was  used 
U/TIME  Uncertainty  reduction  per  unit  of  time  to  read  the  indictor 


ID 
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NAME 

U-REDCT 

U/TIME 
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.64 
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.04 
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.20 
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32 
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32 
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42 
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83 
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3 
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Analysis  of  Diagnostic  Impasses 
(lists  failures  which  could  not  be  resolved  via  testing) 


BB  6  (RU  4  "4060  CLOCK  DRIVER")  had  multiple  RU's  suspect  at  problem  end 

In  2  trials  this  RU  set  was  suspect:  345 
Ave  $cost«  1.00  ave  timecost-  242.00 

BB  9  (RU  5  "CRYSTAL_32768HZ")  had  multiple  RU's  suspect  at  problem  end 
In  1  trials  this  RU  set  wa3  suspect:  4  5 

Ave  $cost-  1.00  ave  timecost-  57.00 

BB  17  (RU  16  "Photo-Trans")  had  multiple  RU'3  suspect  at  problem  end 
In  1  trials  this  RU  set  was  suspect:  8  16 
Ave  $cost«  1.00  ave  timecost-  427.00 

BB  29  (RU  27  "4013  D-FF")  had  multiple  RU's  suspect  at  problem  end 

In  1  trials  this  RU  set  was  suspect:  24  27 
Ave  $cost»  1.00  ave  timecost-  53.00 

BB  31  (RU  24  "4081a")  had  multiple  RU's  suspect  at  problem  end 

In  1  trials  this  RU  set  was  suspect:  24  26  27 
Ave  $cost-  1.00  ave  timecost-  57.00 

BB  32  (RU  28  "4060  CLOCK")  had  multiple  RU's  suspect  at  problem  end 

In  l  trials  this  RU  set  was  suspect:  28  29 
Ave  Scost-  1.00  ave  timecost-  427.00 

BB  40  (RU  29  "Crystal")  had  multiple  RU'3  suspect  at  problem  end 
In  2  trials  this  RU  set  was  suspect:  28  29 
Ave  Ocost"  1.00  ave  timecost—  57.00 

BB  45  (RU  22  "S/P  Converter")  had  multiple  RU's  suspect  at  problem  end 
In  l  trials  this  RU  set  was  suspect:  22  36 
Ave  Ocost-  1.00  ave  timecost—  21.00 

BB  46  (RU  22  "S/P  Converter")  had  multiple  RU's  suspect  at  problem  end 
In  1  trials  this  RU  set  was  suspect:  22  23  25 
Ave  Ooost-  1.00  ave  timecost-  53.00 


Analysis  of  False  Replacements 

Like  an  expert  repair  technician,  PROFILE  will  sometimes  replace  a 
component  which  turns  out  to  be  operational.  This  occurs  when  either 

a.  the  component  is  inexpensive,  and  easily  replaced,  and  is  easier 
to  replace  than  to  test 

or 

b.  the  system  design  does  not  offer  sufficient  testing  points  to  determine  the 
true  source  of  the  failure. 


FREQ  No.  of  times  the  component  was  falsely  replaced,  in  the  sample 

TIME  Total  time  spent  replacing  the  component  when  it  was  O.K. 

SCO  ST  Total  spares  cost  consumed  when  component  was  O.K. 


ID 
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FREQ 
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6 
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9 
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9 
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1 
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1 
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6 
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